1. Field of the Invention
The present invention generally relates to the field of computers. More specifically, the present invention relates to debugging.
2. Description of the Related Art
In concurrent software it is often important to guarantee that one thread cannot observe partial results of an operation being executed by another thread. This guarantee is necessary for practical and productive software development, because it is difficult to reason about the interactions of concurrent threads without the guarantee.
In conventional software practice, this guarantee is typically provided by using locks to prevent other threads from accessing the data affected by an ongoing operation. Such use of locks gives rise to a number of well-known problems, both in terms of software engineering and in terms of performance.
Transactional memory (TM) allows the programmer to think as if multiple memory locations can be accessed and/or modified in a single atomic step. Thus, in many cases, it is possible to complete an operation with no possibility of another thread observing partial results, even without holding any locks. This significantly simplifies the design of concurrent programs. In particular, programmers are relieved of the burden of deciding which locks must be held and when the locks must be held in order to ensure correctness. Transactional memory also relieves the burden of the complexity introduced by the need to avoid deadlock and to achieve scalable performance. Transactional memory can be implemented in hardware, with the hardware directly ensuring that a transaction is atomic, or in software that provides the “illusion” that the transaction is atomic, even though in fact it is executed in smaller atomic steps by the underlying hardware. Recently, substantial progress has been made in making software transactional memory (STM) practical. Nonetheless, there is a growing consensus that at least some hardware support for transactional memory is desirable, and several proposals for supporting TM in hardware (HTM) have emerged. Recently, Hybrid TM (HyTM) has been proposed, which provides a fully functional STM implementation that can exploit best-effort HTM support to boost performance if HTM support is available and when the HTM is effective. Relieving hardware designers of the burden of handling all transactions in hardware allows them to consider a much wider range of designs, and in particular allows them to provide significant benefit with simple designs that handle the common case efficiently, while leaving difficult and/or uncommon cases to the software.
The TM designs (HTM, STM, or HyTM) proposed to date do not address the issue of debugging programs that use them. While TM promises to substantially simplify the development of correct concurrent programs, it is clear that programmers will still need to debug code while it is under development.
Debugging poses challenges for all forms of TM. If HTM is to provide support for debugging, it will be even more complicated than current proposals. STM provides the “illusion” that transactions are executed atomically, while in fact they are implemented by a series of smaller steps. If a standard debugger were used with an STM implementation, it would expose this illusion, creating significant confusion for programmers, thus severely undermining the main advantage of transactional programming. HyTM is potentially susceptible to both challenges.